<html>
<head><meta charset="utf-8"><title>Read, Write, AsyncRead, and AsyncWrite in core · t-libs · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/index.html">t-libs</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html">Read, Write, AsyncRead, and AsyncWrite in core</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="245313876"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245313876" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245313876">(Jul 08 2021 at 13:40)</a>:</h4>
<p>It's pretty important to the embedded rust ecosystem that we have standardized (or at least blessed) versions of <code>Read</code>, <code>Write</code>, <code>AsyncRead</code>, and <code>AsyncWrite</code> available for no_std environments. Obviously, the <code>Read</code> and <code>Write</code> traits from <code>std</code> can't be directly  used because of <code>io::Error</code>, so they need to be new traits with some sort of adapter between the core and std versions.</p>
<p>The jist of what I'm proposing is the 4 new traits, all with associated <code>Error</code>types. Here's a gist with the API sketched out: <a href="https://gist.github.com/rust-play/f65c6e90c748c0c4b2ecef9f1d8f3bde">https://gist.github.com/rust-play/f65c6e90c748c0c4b2ecef9f1d8f3bde</a>.</p>
<p>I'd love to get some feedback about whether this is something that's desirable outside of embedded rust and any suggestions for api changes are of course appreciated.</p>



<a name="245361313"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245361313" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Pratt <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245361313">(Jul 08 2021 at 19:40)</a>:</h4>
<p>I'm fairly certain the long-term plan is to merge core, alloc, and std into a single crate where feature flags (as with any other crate) are used to control the differences. This would permit lots of things (including <code>Read</code> and <code>Write</code>), as the limiting factor would no longer apply.</p>



<a name="245361333"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245361333" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Pratt <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245361333">(Jul 08 2021 at 19:40)</a>:</h4>
<p>I believe <span class="user-mention" data-user-id="220273">@Jane Lusby</span> has been working on this some if she has anything to add.</p>



<a name="245364499"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245364499" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245364499">(Jul 08 2021 at 20:04)</a>:</h4>
<p><span class="user-mention silent" data-user-id="338469">Lachlan Sneff</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245313876">said</a>:</p>
<blockquote>
<p>It's pretty important to the embedded rust ecosystem that we have standardized (or at least blessed) versions of <code>Read</code>, <code>Write</code>, <code>AsyncRead</code>, and <code>AsyncWrite</code> available for no_std environments. Obviously, the <code>Read</code> and <code>Write</code> traits from <code>std</code> can't be directly  used because of <code>io::Error</code>, so they need to be new traits with some sort of adapter between the core and std versions.</p>
</blockquote>
<p>You say this is obvious so maybe this is a silly question but can you describe more concretely what problem are you running into where you need <code>Read</code>/<code>Write</code> to be in core?</p>



<a name="245364622"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245364622" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245364622">(Jul 08 2021 at 20:05)</a>:</h4>
<p>I'm not opposed, assuming it can be done without breakage, but I want to have a better idea of the reason.</p>



<a name="245364677"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245364677" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245364677">(Jul 08 2021 at 20:05)</a>:</h4>
<p>Using the error trait as an example, that's needed so that libraries that are written to work for both no-std and std can be used by std applications and still get composable error reporting</p>



<a name="245364776"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245364776" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245364776">(Jul 08 2021 at 20:06)</a>:</h4>
<p>but I'd worry about the associated type in the core trait versions making it incompatible with other write impls from std and friends when the error types don't match, which would be for every impl that doesn't use <code>io::Error</code>, so I don't see how this would help with interoperability.</p>



<a name="245364996"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245364996" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245364996">(Jul 08 2021 at 20:08)</a>:</h4>
<p>though there could probably be adapters that convert non io::Error types into io::Errors</p>



<a name="245364998"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245364998" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245364998">(Jul 08 2021 at 20:08)</a>:</h4>
<p>hmmm</p>



<a name="245366793"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245366793" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245366793">(Jul 08 2021 at 20:20)</a>:</h4>
<p><span class="user-mention" data-user-id="220273">@Jane Lusby</span> Sorry, I didn't mean to put it like that! The reason why I think having versions of all four traits in core  is important is because there's a budding ecosystem of networking libraries (e.g. TLS implementations, networking peripheral drivers, things like that) designed for use with embedded rust that need a shared vocabulary of abstractions to be able to compose effectively.</p>



<a name="245366842"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245366842" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245366842">(Jul 08 2021 at 20:21)</a>:</h4>
<p>that makes sense</p>



<a name="245367009"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245367009" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245367009">(Jul 08 2021 at 20:23)</a>:</h4>
<p>And I share your hesitancy with the associated error type, but I think it's better than having a single io::Error type for core. For example, I think it would make sense for a TLS implementation to return a "TlsError", which could be surfaced to the user of the networking library, if that's the context.</p>



<a name="245367121"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245367121" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245367121">(Jul 08 2021 at 20:23)</a>:</h4>
<p>i think a good first step would be to find at least a few libraries that would be using this type and get a proof of concept of how they'd use the trait and how it would compose</p>



<a name="245367240"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245367240" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245367240">(Jul 08 2021 at 20:24)</a>:</h4>
<p>That totally makes sense. I'll give that a try.</p>



<a name="245369528"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245369528" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245369528">(Jul 08 2021 at 20:43)</a>:</h4>
<p>On the context of core::io &lt;-&gt; std::io:</p>
<p><span class="user-mention silent" data-user-id="220273">Jane Lusby</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245364996">said</a>:</p>
<blockquote>
<p>though there could probably be adapters that convert non io::Error types into io::Errors</p>
</blockquote>
<p>Yeah, there would either have to be an adapter type that converts a std::io::* to core::io::*, with the Error type set to <code>std::io::Error</code>, or maybe there could be a blanket impl in one direction or the other but I'm not sure.</p>



<a name="245378107"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245378107" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245378107">(Jul 08 2021 at 22:05)</a>:</h4>
<p>strawman proposal: but I imagine it would be a wrapper with a blanket impl of Read/Write where <code>io::Error: From&lt;Inner::Error&gt;,</code></p>



<a name="245378255"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245378255" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245378255">(Jul 08 2021 at 22:07)</a>:</h4>
<p>though actually hmm</p>



<a name="245378256"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245378256" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245378256">(Jul 08 2021 at 22:07)</a>:</h4>
<p>no</p>



<a name="245378283"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245378283" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245378283">(Jul 08 2021 at 22:07)</a>:</h4>
<p>that wouldn't work because the no-std crates would never be able to write the From impl for the conversino</p>



<a name="245378307"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245378307" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245378307">(Jul 08 2021 at 22:07)</a>:</h4>
<p>so I expect it would have to be <code>where Inner::Error: core::error::Error</code></p>



<a name="245378314"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245378314" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245378314">(Jul 08 2021 at 22:07)</a>:</h4>
<p>so this probably also depends on moving the error trait into core</p>



<a name="245393122"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245393122" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245393122">(Jul 09 2021 at 02:14)</a>:</h4>
<p>There might also be weird interference, like if core::Read is implemented for &amp; [u8] and so is std::Read, there couldn't be a blanket impl I think</p>



<a name="245404581"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245404581" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Kestrer <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245404581">(Jul 09 2021 at 06:04)</a>:</h4>
<p>Could the <code>std::io</code> traits just become trait aliases for the <code>core::io</code> traits?</p>



<a name="245432686"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245432686" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245432686">(Jul 09 2021 at 11:51)</a>:</h4>
<p>I made an irlo post a week ago or so about that (<a href="https://internals.rust-lang.org/t/let-trait-aliases-be-used-in-impls-or-how-to-add-io-read-write-to-libcore/14975">https://internals.rust-lang.org/t/let-trait-aliases-be-used-in-impls-or-how-to-add-io-read-write-to-libcore/14975</a>). It seems like it wouldn't really work</p>



<a name="245503490"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245503490" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Kestrer <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245503490">(Jul 09 2021 at 21:29)</a>:</h4>
<p>Those issues are not unresolvable. To me it would make sense to just forbid <code>impl X for T</code> where <code>X</code> is not a single trait.</p>



<a name="245562917"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245562917" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245562917">(Jul 10 2021 at 17:46)</a>:</h4>
<p>Is it worth bringing that up to the lang team?</p>



<a name="245842101"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245842101" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245842101">(Jul 13 2021 at 15:27)</a>:</h4>
<p>I've been trying out implementations of this and there are issues with default implementations of <code>read_all</code>, <code>write_all</code>, <code>write_fmt</code>, and others needing to be able to introspect the error returned by <code>read</code> or <code>write</code>. So, I'm not sure the associated error type is going to work after all, if this needs to be the same trait as in <code>std</code>.</p>



<a name="245844270"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245844270" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245844270">(Jul 13 2021 at 15:43)</a>:</h4>
<p>Yea, introducing a  new trait is unlikely to fly based on previous experience</p>



<a name="245844280"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245844280" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245844280">(Jul 13 2021 at 15:43)</a>:</h4>
<p>New error trait*</p>



<a name="245844414"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245844414" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245844414">(Jul 13 2021 at 15:44)</a>:</h4>
<p>But if you can add one in a way that won't contribute to ecosystem fragmentation then naybe</p>



<a name="245849350"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245849350" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245849350">(Jul 13 2021 at 16:19)</a>:</h4>
<p>It's not that I need a new trait really, just that default methods need to return additional errors.</p>
<p>For example, here's the default implementation of <code>write_all</code> from the <code>Write</code> trait:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="w">    </span><span class="k">fn</span> <span class="nf">write_all</span><span class="p">(</span><span class="o">&amp;</span><span class="k">mut</span><span class="w"> </span><span class="bp">self</span><span class="p">,</span><span class="w"> </span><span class="k">mut</span><span class="w"> </span><span class="n">buf</span>: <span class="kp">&amp;</span><span class="p">[</span><span class="kt">u8</span><span class="p">])</span><span class="w"> </span>-&gt; <span class="nb">Result</span><span class="o">&lt;</span><span class="p">()</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">        </span><span class="k">while</span><span class="w"> </span><span class="o">!</span><span class="n">buf</span><span class="p">.</span><span class="n">is_empty</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">            </span><span class="k">match</span><span class="w"> </span><span class="bp">self</span><span class="p">.</span><span class="n">write</span><span class="p">(</span><span class="n">buf</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">                </span><span class="nb">Ok</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">                    </span><span class="k">return</span><span class="w"> </span><span class="nb">Err</span><span class="p">(</span><span class="n">Error</span>::<span class="n">new_const</span><span class="p">(</span><span class="w"></span>
<span class="w">                        </span><span class="n">ErrorKind</span>::<span class="n">WriteZero</span><span class="p">,</span><span class="w"></span>
<span class="w">                        </span><span class="o">&amp;</span><span class="s">"failed to write whole buffer"</span><span class="p">,</span><span class="w"></span>
<span class="w">                    </span><span class="p">));</span><span class="w"></span>
<span class="w">                </span><span class="p">}</span><span class="w"></span>
<span class="w">                </span><span class="nb">Ok</span><span class="p">(</span><span class="n">n</span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="n">buf</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="o">&amp;</span><span class="n">buf</span><span class="p">[</span><span class="n">n</span><span class="o">..</span><span class="p">],</span><span class="w"></span>
<span class="w">                </span><span class="nb">Err</span><span class="p">(</span><span class="k">ref</span><span class="w"> </span><span class="n">e</span><span class="p">)</span><span class="w"> </span><span class="k">if</span><span class="w"> </span><span class="n">e</span><span class="p">.</span><span class="n">kind</span><span class="p">()</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="n">ErrorKind</span>::<span class="n">Interrupted</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>
<span class="w">                </span><span class="nb">Err</span><span class="p">(</span><span class="n">e</span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="k">return</span><span class="w"> </span><span class="nb">Err</span><span class="p">(</span><span class="n">e</span><span class="p">),</span><span class="w"></span>
<span class="w">            </span><span class="p">}</span><span class="w"></span>
<span class="w">        </span><span class="p">}</span><span class="w"></span>
<span class="w">        </span><span class="nb">Ok</span><span class="p">(())</span><span class="w"></span>
<span class="w">    </span><span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>I think the only solutions to this, if there's to be a <code>core::io::Write</code> trait that returns an associated error type instead of a single <code>core::io::Error</code> type, is to either not implement the method by default or to return <code>Error&lt;Self::Errror&gt;</code> where</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="k">enum</span> <span class="nc">Error</span><span class="o">&lt;</span><span class="n">E</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="n">Other</span><span class="p">(</span><span class="n">E</span><span class="p">),</span><span class="w"></span>
<span class="w">    </span><span class="n">WriteZero</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">FormatterError</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">UnexpectedEof</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="c1">// ...</span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="245867648"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245867648" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245867648">(Jul 13 2021 at 18:31)</a>:</h4>
<p>Well you know one solution would be to not move these APIs into <code>core</code>, and to move them into <code>alloc</code> instead, as the only thing that keeps <code>Error</code> out of <code>core</code> is its dynamic boxed variant. That’s not as perfect as having <code>Error</code> available in <code>core</code>, but it would still cover most if not all of the use cases for taking these traits out of <code>std</code>.</p>
<p>Like if you’re an executable performing I/O you’re in an environment that can do some kind of dynamic allocation, because it needs to be able to handle files of unknown size, sockets with different MTUs, etc.</p>
<p>Even in restrictive environments, you could use an allocator that uses a fixed amount of scratch space.</p>



<a name="245867897"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245867897" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245867897">(Jul 13 2021 at 18:33)</a>:</h4>
<blockquote>
<p>as the only thing that keeps Error out of core is its dynamic boxed variant.</p>
</blockquote>
<p>And <code>last_os_error()</code>.</p>



<a name="245868261"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245868261" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245868261">(Jul 13 2021 at 18:36)</a>:</h4>
<p>@Lachlan Sneff another option is to introduce a core::io::Error type without allocations, still have an associated error, but have a bound on the associated error to require it implementes From&lt;core::io::Error&gt;</p>



<a name="245869624"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245869624" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245869624">(Jul 13 2021 at 18:47)</a>:</h4>
<p><span class="user-mention" data-user-id="133247">@bjorn3</span> Forgot about that function. Though it wouldn’t be a breaking change to have that only available in <code>std</code>.</p>



<a name="245870271"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245870271" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245870271">(Jul 13 2021 at 18:52)</a>:</h4>
<p>There is currently no way to define an inherent method for a type in a different crate. (with the exception of some lang items to implement inherent methods for specific primitive types)</p>



<a name="245870545"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245870545" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245870545">(Jul 13 2021 at 18:54)</a>:</h4>
<p>A lot of problems with the libcore/liballoc/libstd split could be fixed I think by adding a loophole to lift this restriction and the coherence restrictions for these crates. (It should still check that combining libcore+liballoc and libcore+liballoc+libstd are still coherent as a whole though)</p>



<a name="245870859"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245870859" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245870859">(Jul 13 2021 at 18:56)</a>:</h4>
<p>I think the plan is to just merge them into one crate and use build-std for conditional compilation of the pieces</p>



<a name="245871092"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245871092" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245871092">(Jul 13 2021 at 18:58)</a>:</h4>
<p><span class="user-mention" data-user-id="133247">@bjorn3</span> Well you could have one more crate (insert XKCD here) called <code>error</code> or whatever that has different features enabled when imported into std vs alloc/core.</p>



<a name="245871139"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245871139" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245871139">(Jul 13 2021 at 18:59)</a>:</h4>
<p><span class="user-mention silent" data-user-id="220273">Jane Lusby</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245870859">said</a>:</p>
<blockquote>
<p>I think the plan is to just merge them into one crate and use build-std for conditional compilation of the pieces</p>
</blockquote>
<p>I very much dislike that. It depends on the hypothetical portability lint to ensure that you can check that your crate only depends on what you think it depends on. (How many years will it take before we get it?) In addition it isn't possible at the moment because libstd has <a href="http://crates.io">crates.io</a> dependencies that depend on libcore.</p>



<a name="245871340"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245871340" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245871340">(Jul 13 2021 at 19:00)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219696">XAMPPRocky</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245871092">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> Well you could have one more crate (insert XKCD here) called <code>error</code> or whatever that has different features enabled when imported into std vs alloc/core.</p>
</blockquote>
<p>That only works with <code>-Zbuild-std</code>. For the version without <code>-Zbuild-std</code> the std feature flag would always have to be enabled if the target supports libstd, even if you explicitly want to avoid it for whatever reason.</p>



<a name="245871435"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245871435" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245871435">(Jul 13 2021 at 19:01)</a>:</h4>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245871139">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="220273">Jane Lusby</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245870859">said</a>:</p>
<blockquote>
<p>I think the plan is to just merge them into one crate and use build-std for conditional compilation of the pieces</p>
</blockquote>
<p>I very much dislike that. It depends on the hypothetical portability lint to ensure that you can check that your crate only depends on what you think it depends on. (How many years will it take before we get it?) In addition it isn't possible at the moment because libstd has <a href="http://crates.io">crates.io</a> dependencies that depend on libcore.</p>
</blockquote>
<p>I think<br>
<span class="user-mention silent" data-user-id="133247">bjorn3</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245870545">said</a>:</p>
<blockquote>
<p>A lot of problems with the libcore/liballoc/libstd split could be fixed I think by adding a loophole to lift this restriction and the coherence restrictions for these crates. (It should still check that combining libcore+liballoc and libcore+liballoc+libstd are still coherent as a whole though)</p>
</blockquote>
<p>would be much easier to implement than merging libcore/liballoc/libstd.</p>



<a name="245871558"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245871558" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245871558">(Jul 13 2021 at 19:02)</a>:</h4>
<p>Merging libcore/liballoc/libstd also has teachability problems, as it is no longer clear what exactly is available when libstd can't be used.</p>



<a name="245871807"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245871807" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245871807">(Jul 13 2021 at 19:03)</a>:</h4>
<p>Yeah the single crate is a plan, but it’s been a plan for long time and there’s not been much traction AFAICT other than agreement, I remember this same discussion around including extern crates in std in 2018.</p>



<a name="245872630"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245872630" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245872630">(Jul 13 2021 at 19:09)</a>:</h4>
<p>I kinda still think one big crate would be nice, one big crate could make it easier for std to become pluggable for custom targets. There are targets that can’t ever be part of upstream which are able to support std, so it’d be nice if you could provide your own <code>sys</code> implementation without needing to fork the compiler.</p>



<a name="245873094"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245873094" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245873094">(Jul 13 2021 at 19:13)</a>:</h4>
<p>Such <code>sys</code> implementations should be their own crate, right? They would need to depend on <code>core</code> and <code>alloc</code>, but can't depend on <code>std</code> I think.</p>



<a name="245873180"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245873180" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245873180">(Jul 13 2021 at 19:13)</a>:</h4>
<p>Also <code>core</code> and <code>alloc</code> are completely system independent and thus wouldn't need a <code>sys</code> implementation. <code>std</code> is not system independent.</p>



<a name="245877616"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245877616" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245877616">(Jul 13 2021 at 19:49)</a>:</h4>
<p>Looks like the two options so far are</p>
<ol>
<li>
<p>Add an <code>alloc::io::Error</code> type and put <code>Read</code>/<code>Write</code>/<code>AsyncRead</code>/<code>AsyncWrite</code> in <code>alloc</code> instead of core.</p>
<p>a) does this mean that <code>Error</code> would be generic on the allocator somehow?</p>
</li>
<li>
<p>Add a <code>core::io::Error</code> type and require that the trait's associated <code>Error</code> type implements <code>From&lt;core::io::Error&gt;</code>.</p>
</li>
</ol>
<p>I guess this really depends on whether these traits are going to be the same traits as in <code>std</code>.</p>



<a name="245879357"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245879357" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245879357">(Jul 13 2021 at 20:02)</a>:</h4>
<p>Could <code>last_os_error</code> be in an extension trait on <code>alloc::io::Error</code>?</p>



<a name="245879637"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245879637" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245879637">(Jul 13 2021 at 20:04)</a>:</h4>
<p>I am not sure if that is backwards compatible even if you add it to the prelude.</p>



<a name="245879734"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245879734" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245879734">(Jul 13 2021 at 20:05)</a>:</h4>
<p>No, it isn't. If you use <code>#![no_std] extern crate std; use std::io::Error;</code> the extension trait will not be imported.</p>



<a name="245879906"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245879906" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245879906">(Jul 13 2021 at 20:06)</a>:</h4>
<p>And I would guess it's too late to make it into the new edition?</p>



<a name="245879992"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245879992" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245879992">(Jul 13 2021 at 20:07)</a>:</h4>
<p><code>use ErrorExt as _</code> would be fine to add to the prelude I think even without a new edition.</p>



<a name="245880350"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245880350" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245880350">(Jul 13 2021 at 20:10)</a>:</h4>
<p>Right, but it'd be a breaking change in that contrived case, so it'd need to be in an edition, I think.</p>



<a name="245883271"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245883271" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lachlan Sneff <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245883271">(Jul 13 2021 at 20:32)</a>:</h4>
<p>Also, if Read, Write, and friends require alloc, they're not going to be widely used in embedded rust, where they'd be most useful.</p>



<a name="245883498"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245883498" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245883498">(Jul 13 2021 at 20:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="338469">Lachlan Sneff</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245880350">said</a>:</p>
<blockquote>
<p>Right, but it'd be a breaking change in that contrived case, so it'd need to be in an edition, I think.</p>
</blockquote>
<p><code>#![no_std] extern crate std;</code> isn't that contrived. It's often used when no_std is conditional, as It makes it easier to avoid accidentally using stuff from the prelude.</p>



<a name="245891322"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245891322" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245891322">(Jul 13 2021 at 21:22)</a>:</h4>
<p><span class="user-mention" data-user-id="133247">@bjorn3</span> In reality though std allows targets to pick and choose what they support, a lot of platforms just provide stub APIs that always return <code>Err</code>. So with that in mind <code>std</code> could allow you to override the parts you want with your own system, while defaulting to unsupported for everything else.</p>
<p>This also works well with the of it all being one crate and you just get the “features” you need, this would be extending those features to also include things like the filesystem abstraction and sockets.</p>



<a name="245891660"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245891660" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245891660">(Jul 13 2021 at 21:24)</a>:</h4>
<p>Returning Err/panicking for unsupported things on wasm has been a mistake IMO. Without portability lint it makes it impossible to test if something works on a target  without running it.</p>



<a name="245891895"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245891895" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245891895">(Jul 13 2021 at 21:27)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/pull/86191#issuecomment-860238906">https://github.com/rust-lang/rust/pull/86191#issuecomment-860238906</a></p>



<a name="245895098"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Read%2C%20Write%2C%20AsyncRead%2C%20and%20AsyncWrite%20in%20core/near/245895098" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core.html#245895098">(Jul 13 2021 at 21:59)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219696">XAMPPRocky</span> <a href="#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core/near/245891322">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> In reality though std allows targets to pick and choose what they support, a lot of platforms just provide stub APIs that always return <code>Err</code>. So with that in mind <code>std</code> could allow you to override the parts you want with your own system, while defaulting to unsupported for everything else.</p>
<p>This also works well with the of it all being one crate and you just get the “features” you need, this would be extending those features to also include things like the filesystem abstraction and sockets.</p>
</blockquote>
<p>yea, i think there's been a fair bit of turmoil over whether we should continue to do this</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>